In the past, application programs consisted of a single monolithic binary file. Once a compiler generated the application program, the application program did not change until a next version was recompiled and shipped. Changes in an operating system, hardware and market demands were dependent on waiting for the next version to be implemented and recompiled. Today, application programs are comprised of several components—additionally, many of these components are linked at runtime. These components include dynamically linked libraries (DLLs) and other files that are shared by different application programs. These DLLs are listed within tables in application components to be linked at runtime. An operating system will search in a loader search path, application directory, operating system directory or user specified path for the name of the dynamic linked library, so that DLL code can be loaded into memory for execution. Since these DLLs can be shared by different application programs, changes to a DLL for one application may cause another application to stop operating.
Furthermore, many application programs running on operating systems, such as Microsoft® Windows® Operating System employ shared operating system components. One of the primary issues faced by administrators and developers on the current Microsoft® Windows@ Operating System platform is the inability to control an exact set of dynamic link libraries and other files that will run as part of a deployed application program. It is quite common to have installation of one application program affect other application programs by overwriting files that those applications depend on. Unfortunately, there is no built in support in Microsoft® Windows® Operating System to detect when a file that an application depends on has changed.
Presently, there has not been a way of tracking assemblies used to build and test application programs. In the past, components may be changed and the application program may still run if the changes do not effect the functionality of the application program. For example, if a publisher of a component corrects a minor error in a component, the application program may still operate without a problem. Also, if a version upgrade has occurred by a publisher, the application program may execute the component without a problem, if the component is backwards compatable. However, there is no way of protecting application programs from versioning upgrades by a publisher of components, if the publisher was wrong about the new version being backwards compatible with the previous components. Furthermore, if the component has been altered by an untrusted third party, execution of the code can result in damage to the software and hardware of the environment that the application program is operating on. Some codes include versioning information in the name of the component (e.g., fool.dll, kernel2.dll). Since application programs reference these components by name, a change in the name will cause the application program to terminate its operation or use an old version of the component residing on the system.
Accordingly, there is an unmet need in the art for a method for ensuring and verifying integrity of components employed by application programs during runtime. There is also a need for a tool for verifying integrity of components at runtime.